home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10138 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.6 KB
  1. Path: news.uiowa.edu!ozone!maclenna
  2. From: maclenna@ozone.uiowa.edu (Mark MacLennan)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 6 Mar 1996 08:08:12 GMT
  6. Organization: University of Iowa, Iowa City, IA, USA
  7. Distribution: world
  8. Message-ID: <4hjh5c$elk@flood.weeg.uiowa.edu>
  9. References: <4hj8ek$elu@sam.inforamp.net>
  10. Reply-To: maclenna@cgrer.uiowa.edu (Mark MacLennan)
  11. NNTP-Posting-Host: ozone.cgrer.uiowa.edu
  12.  
  13. In article <4hj8ek$elu@sam.inforamp.net>
  14. rmorin@inforamp.net (Randy Charles Morin) writes:
  15. >The company I just started a contract with gave me a set of C++ coding 
  16. >standards.  I started reading and couldn't stop laughing.  I can't reproduce 
  17. >them word-for-word, because that wouldn't be nice to the authors and might be 
  18. >considered a copyright violation or privacy violation, but I'll outline some 
  19. >of the points.
  20.  
  21. Some of their coding standards requirements you list are actually
  22. quite good, some are more dubious.  Most coding standards are intended
  23. as guidelines to be followed unless common sense dicticates otherwise
  24. (and these deviations are documented accordingly).  You should probably
  25. discuss this with the company, inquire as to the intent of some of
  26. the standards, rather than laugh behind their back.
  27.  
  28. Some of the items you list reveal your own unfamiliarity with C++,
  29. which is perhaps one reason they have defined a set of C++ coding
  30. standards. (Hopefully the company isn't paying you based on spelling ...)
  31.  
  32. - MARK
  33.  
  34. >
  35. >    -source files should have the extension .cc (not .cpp or .c).
  36. >    -header files should have the extension .hh (not .hpp or .h).
  37. >    -inline C++ functions should be in a file with the extension .icc 
  38. >           (not in the primary header).
  39.  
  40. The latter is a little unusual but no big deal.  They can always
  41. edit things how they like later.
  42.  
  43. >    -do not use the /* */ comment, except when commenting out entire 
  44. >sections of code.  My understanding is that /* */ comments are ANSI comments, 
  45. >while // comments are not ANSI.
  46.  
  47. Your understanding is wrong.  Both forms are acceptable.
  48.  
  49. >    -a class which can be instantiated with a "new" must have a copy 
  50. >constructor, a destructor and an assignment operator definition.  This will 
  51. >extend the project another month. 
  52.  
  53. Huh?  It isn't that hard to do - maybe the company is planning ahead
  54. and anticipating the re-use of these classes by other programmers.
  55.  
  56. >    -never use #define instead or const.  What if your concerned about the 
  57. >mix between code space and data space.
  58.  
  59. Not bad advice.  Pre-processor directives should be avoided if possible.
  60. Better error checking too.
  61.  
  62. >    -variable are to be declared with the smallest possible scope.
  63. >        void c::f() 
  64. >        { 
  65. >            {
  66. >                int b; 
  67. >                {
  68. >                    int a;
  69. >                    a=b+c; 
  70. >                    b=a+d; 
  71. >                }
  72. >                e=b+d; 
  73. >            } 
  74. >            f=e+4;    
  75. >        }
  76. >        this type of optimization could take forever.
  77.  
  78. Use common sense when applying rules such as this.  In it's strictest
  79. form it may not be appropriate.  It is a good idea to keep variables
  80. local to where they are actually used.
  81.  
  82. >    -don't use explicit type conversions.  In other words, don't program 
  83. >in windows.  Explicit type conversion is necessary  to convert GDI object 
  84. >handles.
  85. >    -don't use implicit type conversions implicitly, use them explicitly. 
  86. > Hello!
  87.  
  88. These standards are a little odd but that may be how you worded them.
  89. Avoiding implicit type conversions is not such a back idea (use casts
  90. to explicitedly show the conversion).
  91.  
  92. >    -every case statement must be terminated with a break statement.  What 
  93. >if you want to step through more then one case statement?
  94.  
  95. Simply document the exception to the rule ...
  96.  
  97. >        case ENGINE_NOT_ACTIVE:
  98. >            start_engine();
  99. >        case ENGINE_ACTIVE_NOT_IN_DRIVE:
  100. >            shift_to_drive();
  101. >        case ENGINE_ACTIVE_IN DRIVE:
  102. >            press_accelerator();
  103. >            break;
  104.  
  105. >    -don't use conditional compilation preprocessor directives.  There 
  106. >goes cross-platform development.
  107.  
  108. Huh?  Since these are pre-processor commands, simply run your code 
  109. through the pre-processor for the particular platform your client wants
  110. the software for.  What's the big deal from your point-of-view?  Out-of-
  111. curiousity, I would inquire as to why they have this programming standard.
  112.  
  113. >    -optimize code only when you have a problem.  So we can't optimize 
  114. >size in order to anticipate that code size will be a problem.  First we have 
  115. >to experience the problem (most likely in the field).
  116.  
  117. Perhaps they want well-written code that they and other
  118. future programmers can read rather than tricky "optimized" code.
  119. The code can always be tweaked for specific hardware at a later
  120. time.  There is no reason that you can't write efficient code using
  121. appropriate algorithms and data structures.
  122.  
  123. >    -access functions are to be inline.  Inline access functions defeat 
  124. >the purpose of having access functions.
  125.  
  126. This isn't clear.  Having access functions inplemented inline isn't
  127. such a bad idea.
  128.  
  129. >    -give protected accessors for all data members.  What if we need to 
  130. >make the accessor public.  Should we define one protected and one public.
  131.  
  132. Accessor functions aren't "data members".  Keeping your data isolated
  133. to a particular class and only accessible through accessor functions
  134. is a good idea.
  135.  
  136. >    -++ and -- operations should be on a separate line.
  137. >        for (i=0; i<0;
  138. >            i++
  139. >        );
  140. >        Is that better?
  141.  
  142. Since the ";" is a statement separator and essentially equivalent to 
  143. their intent of "separate lines" you needn't do the above.  You seem
  144. to miss the point of this standard - they want to avoid problems with
  145. side effects.
  146.  
  147. >    -don't allocate memory and expected someone else will delete it later. 
  148. >Can't use OWL, because control classes are automatically deleted for you.
  149.  
  150. This is very good advice - obviously it doesn't apply for packages such
  151. as OWL which do it for you.
  152.  
  153.